Asynchronous transfer of requests or messages between application programs running on different data processing systems within a network is well known in the art and is implemented, for example, by a number of commercially available messaging systems. These systems include IBM Corporation's MQSeries® family of messaging products, which use asynchronous messaging via queues. A sender application program issues a PutMessage command to send (put) a message to a target queue, and MQSeries queue manager programs handle the complexities of transferring the message under transactional control from the sender application to the target queue, which may be remotely located across a heterogeneous computer network. The target queue is a local input queue for another application program, which retrieves (gets) the message from this input queue by issuing a GetMessage command asynchronously from the send operation. The receiver application program then performs its processing on the message, and may generate further messages. MQSeries and IBM are trademarks of International Business Machines Corporation.
Transference of messages carried out under transaction control gives assured once and once-only message delivery of messages even in the event of system or communications failures. A feature of such transactional control is that a message that is put to a target queue does not become available on the target queue until the transaction, under which it is put to the queue, is committed. Once the transaction is committed the message is delivered to the target queue and the receiver application can get and use the message as a trigger to carry out a unit of work, which may be done under the scope of a second transaction. This delay of sending the message is considered necessary because the result of rolling back a transaction under which a message is sent must be the same as if the message was not sent.
However this behaviour has two drawbacks. One is that a transaction can succeed whilst the work done on its behalf as a result of sending a message can fail. The second is that two transactions are involved in processing the sending of the message and the work done as a result of the message, when performance might be better served by completing the work under a single transaction as this can require less logging.